Date: Fri, 26 Aug 94 04:30:20 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #285 

To: Ham-Digital 


Ham-Digital Digest Fri, 26 Aug 94 Volume 94 : Issue 285 


Today's Topics: 
HF -> internet gateways? 
HF Packet (Mac vs PC) 
HP100LX + Baycomm = Success? 
jnos trace question (2 msgs) 
jnos w/enet card 
mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies 
Packet Routing with JNOS 110f 
What SB for Digital modes? 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 25 Aug 1994 23:37:22 GMT 
From: andyh@ucsd.edu 

Subject: HF -> internet gateways? 
To: ham-digital@ucsd.edu 


i'm looking for gateways which can receive pactor, amtor, gtor or 
rtty messages on HF and send them to an internet e-mail address. 


i'd be most grateful if anyone who knows of such things could 
email me details. i'll compile and post the results. 


thanks, 


andy howard <andyh@burn.ucsd.edu> 


Date: 25 Aug 1994 03:01:52 GMT 

From: news.sprintlink.net!sun.cais.com!news.cais.com!news@uunet.uu.net 
Subject: HF Packet (Mac vs PC) 

To: ham-digital@ucsd.edu 


Go ahead and get a Mac for this project,the software needed for what 
you want to do exists and is sold by the major TNC manufacturers. 

I heartdly recomend a Kam all mode TNC and Hostmaster for Mac from 
Kantronics.If you cant get a source or number for the manufacturer,send 
me some e-mail,I'll get it to you 


Date: Thu, 25 Aug 1994 05:40:07 GMT 

From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!usenet.ins.cwru.edu!news.csuohio.edu! 
sww@network.ucsd.edu 

Subject: HP10OLX + Baycomm = Success? 

To: ham-digital@ucsd.edu 


J. Sherwood Williams (jwill@cabell.vcu.edu) wrote: 


: Has anyone had any success using a Baycom type modem with the HP 
: 100LX palmtop? Before I go out and mess with it, it would be good 


The HP100LX works fine once the Baycom is powered by a 9 volt battery. 
Works even better with a PacComm HandiPacket and MSYS. With that it is a 
full forwarding BBS with all the goodies (node, etc.). In that way 

I can forward to the home BBS when I have mail to deliver and the home 
BBS can forward into me ... if I am there or not. We also ran it with a 
GTOR and Pactor port when running on a battery up in Algonquin Provintial 
Park. Worked great and saved all kinds of amp-hours as I didn't have to 
use the other laptop. 


I love it! 


73, 

Steve 
ag807@cleveland.freenet.edu 
no8m@no8m.#neoh.oh.usa.na 


Date: 25 Aug 1994 13:46:06 GMT 

From: noc.near.net!transfer.stratus.com!abersoch.sw.stratus.com! 
northup@uunet.uu.net 

Subject: jnos trace question 


To: ham-digital@ucsd.edu 


I have just started using jnos110f and have been having a problem 
with having a trace show up on the screen. I can make it go toa 


file. What am I missing ? 

Bill 

Bill Northup PHONE: (508) 460-2085 

Stratus Computer Inc. INTERNET: northup@sw. stratus.com 
55 Fairbanks Boulevard Packet: NIQPR@WALPHY .#EMS.MA.USA.NA 
Marlboro, MA 01752 Amateur Radio: N1QPR 


Date: 25 Aug 1994 08:16:23 -0700 

From: nntp.crl.com!crl4.crl.com!not-for-mail@decwrl.dec.com 
Subject: jnos trace question 

To: ham-digital@ucsd.edu 


In article <33i7au$rri@transfer.stratus.com>, 
northup@abersoch.sw.stratus.com (Bill Northup) wrote: 


> I have just started using jnos110f and have been having a problem 
> with having a trace show up on the screen. I can make it go to a 
> file. What am I missing ? 


An <F9> key. 


After you have entered "Trace xxxx" <ENTER> (where "xxxx" is the 
representation of the type of trace you wish), mash the <F9> key to 
see the results. 


You can tell if you mashed the key hard enough by observing the upper 
left corner of the CRT (3rd line down). It will change from "Command" 
to "Trace". Mashing <F9> again will toggle back to Command Mode. 


If you wish, you can use other F-keys to sequentially observe multiple 
active sessions; <F1i> being session 1, <F2> being session 2, etc. 
Unfortunately, TRACE does not act like an independent session, and the 
TRACE screen will "freeze" if you are watching another session. 


Lou 


Internet: lgenco@crl.com Lou.Genco@LChance.sat.tx.us 
Ham Radio Packet: N5SGL @ K3WGF.4#SAT.TX.USA tcp/ip: n5sgl@sat.ampr.org 


Date: 25 Aug 1994 01:08:48 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov! agate! library.ucla.edu!csulb.edu!nic- 
nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!ix.netcom.com! 
netnews@network.ucsd.edu 

Subject: jnos w/enet card 

To: ham-digital@ucsd.edu 


I am running JNOS 1.10f and have installed gvc ethernet cards in my 
jnos pc and my other pc. The cards check out fine between the machines 
running the diagnostics. The supplied driver comforms to FTP specs. I 
have included the PACKET protocol in my config.h . THe attach works 
fine, but I cannot get jnos to recognize the packets I am sending to 
it. The trace on the port avails nothing. Any ideas or suggestions 
for debugging would greatly be appreciated, especially configuration 
options for jnos I may not have set correctly. Thanks. 

73 de Bill Abernathy, kd5lu. 


Date: Thu, 25 Aug 1994 02:42:38 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net! 
europa.eng.gtefsd.com!ulowell!simtel.coast.net!msdos-ann-request@network.ucsd.edu 
Subject: mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies 

To: ham-digital@ucsd.edu 


I have uploaded to the SimTel Software Repository (available by anonymous 
ftp from the primary mirror site OAK.Oakland.Edu and its mirrors): 


SimTel/msdos/packet/ 
mlhacker.zip Zenith Minisport docs, hints, hacks & goodies 


mlhacker.zip is a compendium of newsletters about the Zenith Minisport 
laptop computer and its use as a packet radio host computer. Zenith 
offers only minimal and expensive support for this popular but 
discontinued 8086 compatible notebook computer. Newsletters contain 
technical notes, construction projects, operating hints, resources, 
architecture details and other related goodies. The Minisport Laptop 
Hacker series is the result of owning and repairing Minisports and 
donations from others on Internet and the Amateur Radio packet networks. 


Special requirements: None 


Changes: Compendium includes Minisport Laptop Hacker #1 - #22. 
FreeText. Uploaded by the author. 


Brian Mork 
bmork@opus-ovh.spk.wa.us 
ka9snf£@ka7£vv.d#ewa.wa.usa 

6006-B Eaker, Fairchild, WA 99011 
V:509-244-3764 D:509-244-9260 


Date: 25 Aug 1994 11:51:22 GMT 

From: news.cerf.net! gopher.sdsc.edu!news.tc.cornell.edu! 
travelers.mail.cornell.edu!news.kei.com!yeshua.marcam.com!zip.eecs.umich.edu! 
newsxfer.itd.umich.edu! gatech!howland.reston@ihnp4.ucsd.edu 

Subject: Packet Routing with JNOS 110f 

To: ham-digital@ucsd.edu 


I want to use JNOS as a packet switch between an AX25 serial link and an 
ether net segment. 


With the autoexec.nos listed below, I can ping machines on the 1.0.0/24 
(ethernet) side of the net and I can ping machines on the 1.0.1/24 
(AX.25) side of the net. The problem I have is that if I try to ping 
say 1.0.0.45 from 1.0.1.99, the packets dont go anywhere. The default 
route on my AX.25 machine is set to: 


route add default sl1 1.0.0.99 


The way I figure it, 1.0.0.99 should see the ping for 1.0.0.45 from 
1.0.1.99 and route ot from the AX.25 side out onto the ether net side 
but this isn't hapening. 


Is there something I'm not doing right? 


By the way, don't get upset about my IP numbers. None of these nets are 
connected to anything and just exist on an experimental test bed. 


iHF ip setup 
ip address 1.0.0.99 
hostname dave.ards.dnd.ca. 


qHE ax25 setup 
ax25 mycall dave 
ax25 bctext "ARDS testbed Daves Machine" 


d#HF attach interfaces 

attach asy Ox3f8 4 ax25 sl1 1025 768 9600 
ifconfig sl1 ipaddress 1.0.1.99 

ifconfig sl1 descr "AX25 Connection to Laptop" 


attach packet 60 lan1 100 1500 
ifconfig lan1 ipaddress 1.0.0.99 
ifconfig lan1 descr "Packet Connection to DLAEEM" 


qHF Start Servers 
start ax25 

start ftp 

start telnet 


dHF Routing 
route add 1.0.1/24 sl1 
route add 1.0.0/24 lant 


ip hport sl11 on 
ip hport lani on 
ax25 hport sli on 


| Captain Dave Mercer M.Eng., P.Eng. 
| Directorate of Land Armament and 
| Electronics Engineering and 

| Maintenance 2-3-3 

| National Defence Headquarters 

| Ottawa, Ontario, Canada 

| K1A OK2 

| 

| Voice: (819) 997-9831 

| Fax: (819) 994-4246 

| EMail: mercer@dgs.dnd.ca 

| HAM: VE3XMJ 


Version: 2.3 


mQCNAiw7 j JkKAAAEEALpAIVUL1A/xvxrzuR30NcLZEOHCHyGm5QR4ej 8xM6k3ACH3T 
Q3NkgV2FK5£8t/£BAhO1+££a5K7FLOB4hHPqKkAASN1kK1PIx9ty5o0UgxAlZnfya4v 
ScNIxOx2h2f£3roRjiZLENYM2zkm26sZhFQJVIxyNnluJq/xVb45/LyY+p9f1AAUR 
tCBEYXZpZCBNZXJjZXIgPG11cmN1lckBuY3MuZG5kLmNhPg== 

=0azF 


Date: Wed, 24 Aug 94 20:27:08 PDT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!howland.reston.ans.net! 
vixen.cso.uiuc.edu!sdd.hp.com!svc.portal.com!portal!cup.portal.com! 
lgm@network.ucsd.edu 

Subject: What SB for Digital modes? 

To: ham-digital@ucsd.edu 


all digital is on LSB on 20 meters 


Date: Thu, 25 Aug 1994 16:34:28 GMT 

From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!europa.eng.gtefsd.com! 
newsxfer.itd.umich.edu!zip.eecs.umich. edu! yeshua.marcam.com!news.kei.com!world! 
dts@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <1994Aug20.143652.9960@ke4zv.atl.ga.us>, <Cuzyol.8tt@world.std.com>, 
<33i45b$o0ao@acorn.acorn.co.uk>.com 
Subject : Re: Looking for DXCluster software 


In article <33i45b$oao@acorn.acorn.co.uk>, 

Adrian Godwin <agodwin@acorn.co.uk> wrote: 

>In article <Cuzyol.8tt@world.std.com>, 

>Daniel T Senie <dts@world.std.com> wrote: 

>> 

>>How is the PacketCluster machine to know that the UI frame with a DX 
>>spot just got stomped by another station starting to transmit a frame? 
>>Packet radio does NOT run with Collision Detection in the way that 
>>Ethernet does. You cannot tell, when transmitting, that your frame 
>>has just gotten munched. 

>> 

> 

>It's not that difficult : most broadcast protocols work on a NAK-only 
>scheme - clients of the server respond only when they miss a packet, 
>and the server than retransmits it. 

>The method of detecting that missed packet varies, but a popular method 
>is to number the transmitted packets and complain when a hole appears in 
>the number sequence. 


Adrian, thanks for your comments, and this is exactly what I was trying 
to call out. There are certainly solutions such as numbered packets 
which can be implemented. Essentially what you're doing then is to 
create another protocol layered atop the broadcast mechanism. It's 


not that different from the multicast implementations. I was primarily 
pinting out that the "simple" solution that had been mentioned was 
not sufficient. 


> 
>This has some difficulties for a DX-Cluster style service : as I understand 
>it (I don't use DX Cluster) you expect transmissions at intervals, rather 
>than a continuous stream. Thus, you wouldn't know you missed one until 

>the next arrived - a second or an hour later. Regular empty packets, sent 
>just to ensure everyone was up to date, might be sufficent to fix this, 
>and there are more sophisticated schemes around to ensure this doesn't 
>itself become a bandwidth hog. These require that the server keep track 

>of its clients rather than doing pure broadcast, but that's no worse than 
>having multiple VCs. 


Exactly. The frequency of packets is an issue. It would be necessary to 
send out null packets every 30 seconds or so to ensure all stations 
received the broadcasts in a timely fashion. Even 30 seconds may be 

too long... At some point you really clog the channel with null packets 
placed there to ensure naks happen correctly when needed... 


> 

>However, I think you're correct to be concerned about low reliability of 
>packet systems - on typical terrestrial packet, the success rate is very 
>low. As a result, a protocol optimised for the assumption that most packets 
>get through (and don't require ACKing) might turn out disastrously wrong - 
>I think a successful broadcast scheme would require both a well-engineered 
>high-reliability transmission scheme (good paths, no hidden terminals etc) 
>and a protocol that gets no worse than multiple-VCs even in poor conditions. 
>It might work pretty well with a full-duplex repeater and extremely well 
>with a polled hub (where a small amount of reverse traffic can be effectively 
>free by imposing no additional overhead) . 

> 

>I don't know how closely satellite operation approaches this (do they split 
>uplink and downlink packet frequencies ? ). I'd be interested to hear from 
>users of the Pacsat broadcast system and even more interested to hear from 
>anyone who has experimented with a terrestrial broadcast setup. 


Dan 

Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 
508-779-0439 Compuserve: 74176 ,1347 


Date: 25 Aug 1994 13:51:55 +0100 


From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!EU.net!uknet!acorn!not-for- 
mail@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <3306v8$jbi@vixen.cso.uiuc.edu>, 
<1994Aug20.143652.9960@ke4zv.atl.ga.us>, <Cuzyol.8tt@world.std.com> 
Subject : Re: Looking for DXCluster software 


In article <Cuzyol.8tt@world.std.com>, 

Daniel T Senie <dts@world.std.com> wrote: 

> 

>How is the PacketCluster machine to know that the UI frame with a DX 
>spot just got stomped by another station starting to transmit a frame? 
>Packet radio does NOT run with Collision Detection in the way that 
>Ethernet does. You cannot tell, when transmitting, that your frame 
>has just gotten munched. 

> 


It's not that difficult : most broadcast protocols work on a NAK-only 
scheme - clients of the server respond only when they miss a packet, 

and the server than retransmits it. 

The method of detecting that missed packet varies, but a popular method 
is to number the transmitted packets and complain when a hole appears in 
the number sequence. 


This has some difficulties for a DX-Cluster style service : as I understand 
it (I don't use DX Cluster) you expect transmissions at intervals, rather 
than a continuous stream. Thus, you wouldn't know you missed one until 

the next arrived - a second or an hour later. Regular empty packets, sent 
just to ensure everyone was up to date, might be sufficent to fix this, 

and there are more sophisticated schemes around to ensure this doesn't 
itself become a bandwidth hog. These require that the server keep track 

of its clients rather than doing pure broadcast, but that's no worse than 
having multiple VCs. 


However, I think you're correct to be concerned about low reliability of 
packet systems - on typical terrestrial packet, the success rate is very 

low. As a result, a protocol optimised for the assumption that most packets 
get through (and don't require ACKing) might turn out disastrously wrong - 

I think a successful broadcast scheme would require both a well-engineered 
high-reliability transmission scheme (good paths, no hidden terminals etc) 
and a protocol that gets no worse than multiple-VCs even in poor conditions. 
It might work pretty well with a full-duplex repeater and extremely well 

with a polled hub (where a small amount of reverse traffic can be effectively 
free by imposing no additional overhead) . 


I don't know how closely satellite operation approaches this (do they split 
uplink and downlink packet frequencies ? ). I'd be interested to hear from 


users of the Pacsat broadcast system and even more interested to hear from 
anyone who has experimented with a terrestrial broadcast setup. 


-adrian 


End of Ham-Digital Digest V94 #285 
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